home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 18394 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.5 KB
  1. Path: news.express.co.nz!usenet
  2. From: bruce@faxmail.co.nz (Bruce Simpson)
  3. Newsgroups: comp.lang.java,comp.lang.c++,comp.sys.mac.oop.misc,comp.lang.basic.visual.misc,comp.sys.mac.programmer.misc,comp.windows.misc
  4. Subject: Re: java vs. multi-platf. frameworks ?
  5. Date: Sat, 20 Apr 1996 07:11:11 GMT
  6. Organization: FaxMail Technologies
  7. Message-ID: <4la66j$ifo@news.express.co.nz>
  8. References: <3171A3EA.3F27@dma.epfl.ch> <Dq0rq5.9sz@unify.com>
  9. Reply-To: bruce@faxmail.co.nz
  10. NNTP-Posting-Host: bsimpson.iprolink.co.nz
  11. X-Newsreader: Forte Free Agent 1.0.82
  12.  
  13. lee@Unify.com (Lee Crocker) wrote:
  14.  
  15. >Sun's current attitude about AWT offers little hope.  They seem to
  16. >think that they can achieve portability by making AWT a subset of the
  17. >functionality of existing GUIs; but that attitude is backwards.  To be
  18. >truly portable, it must be a superset of existing GUIs, emulating those
  19. >functions specific to each on the others in a portable way, and letting
  20. >developers query the system for its capabilities in a portable way.
  21.  
  22. This is a tricky one.  Traditionally multi-platform systems have either
  23. gone the way of "largest common subset" or "emulated superset", both
  24. methods have their pro's and con's.  I expect that in the case of Java, the
  25. largest common subset was the quickest and easiest way to get Java into the
  26. hands of developers on as many platforms as possible.  If they'd gone the
  27. other way we'd all still be playing with console-mode apps at present.
  28.  
  29. Having said that I'd have to agree that the present AWT is sadly lacking -
  30. but it is adequate for the point on the learning curve that many new Java
  31. recruits are at.
  32.  
  33. Let's face it, Java has a way to go yet before its ready for the big-time
  34. and here's hoping that we see an alternative (Sun-approved or sourced)
  35. user-interface class library soon.
  36.  
  37. >There is never any excuse to sacrifice functionality for portability.
  38. >Ever.  Users demand--and rightly so--that they be able to take full
  39. >advantage of every dollar they've spent on their hardware and software,
  40. >and if they hear "well, we could do that but it wouldn't be portable"
  41. >from a vendor, they'll go to a vendor that will do it non-portably.
  42.  
  43. In a production environment that is true - but as I mentioined above,
  44. nobody really believes that Java is ready for production-quality
  45. development yet - or if they do then they may get a few surprises :-)
  46.  
  47. >As a developer, if I can earn 10 cents more by writing a non-portable
  48. >program, I will, without the slightest twinge of guilt.
  49.  
  50. I think that the goal of total platform independence is a laudable one and
  51. given the choice I'd opt for a Java solution every time.  Why should I be
  52. tied to one platform when by using the right tool I can have a much wider
  53. choice.  If the client has performance concerns then they can throw more
  54. silicon at the problem.  Silicon is still a *lot* cheaper than programmer
  55. hours and the price disparity will only widen in the future.
  56.  
  57. >The only way to ensure portability, therefore, is the ensure that a
  58. >portable program is capable of doing everything the software needs 
  59. >to do, and AWT doesn't even come close.  The glaring omissions for
  60. >me are things like right-button popup menus, native video support
  61. >(for example, being able to query the system for its color capabilities
  62. >and things like monitor gamma, and then optimizing my diplay for it),
  63. >portable virtual keys for things like arrow and cut/paste, better
  64. >font metrics, and about 1000 more system properties.
  65.  
  66. It's the eternal tradeoff of complexity versus functionality.  I think
  67. you'll find that most developers will settle for less than 100%
  68. functionality if it means that their job is easier and the results are
  69. acceptable.  Look at the proliferation of tools such as high-level database
  70. languages which are imensely powerful but at the same time force the user
  71. into very narrow design choices in many areas.  Most programmers are more
  72. than happy to accept the limitations in return for the greatly enhanced
  73. productivity or they'd be writing in C/C++.
  74.  
  75. Give the customer the choice between a $100 application that's a 90% fit
  76. and a $10,000 application that's a 100% fit and 99 times out of 100 you'll
  77. sell the $100 app.  Of course there's always room for that $10,000 app and
  78. there will always be a job for those who create them, but I think it's
  79. important to realise where the mainstream markets lie.
  80.  
  81. >Just one man's rant.  Thanks for the soapbox :-)
  82.  
  83. My turn over... next please!  :-)
  84.  
  85. --------------------------------------------------------------
  86. Aardvark - an weekly net-magazine taking a look at the 
  87. internet in NZ and around the world.
  88. http://www.voyager.co.nz/~bsimpson/aardvark.htm
  89.  
  90.